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THE REPLY FILED 06 May 2008 FAILS TO PLACE THIS APPLICATION IN CONDITION FOR ALLOWANCE. 

1 . £3 The reply was filed after a final rejection, but prior to or on the same day as filing a Notice of Appeal. To avoid abandonment of this 

application, applicant must timely file one of the following replies: (1 ) an amendment, affidavit, or other evidence, which places the 
application in condition for allowance; (2) a Notice of Appeal (with appeal fee) in compliance with 37 CFR 41 .31 ; or (3) a Request 
for Continued Examination (RCE) in compliance with 37 CFR 1.114. The reply must be filed within one of the following time 
periods: 

a) K| The period for reply expires 3_months from the mailing date of the final rejection. 

b) CD The period for reply expires on: (1) the mailing date of this Advisory Action, or (2) the date set forth in the final rejection, whichever is later. In 

no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of the final rejection. 

Examiner Note: If box 1 is checked, check either box (a) or (b). ONLY CHECK BOX (b) WHEN THE FIRST REPLY WAS FILED WITHIN TWO 

MONTHS OF THE FINAL REJECTION. See MPEP 706.07(f). 
Extensions of time may be obtained under 37 CFR 1 .136(a). The date on which the petition under 37 CFR 1.136(a) and the appropriate extension fee 
have been filed is the date for purposes of determining the period of extension and the corresponding amount of the fee. The appropriate extension fee 
under 37 CFR 1.17(a) is calculated from: (1) the expiration date of the shortened statutory period for reply originally set in the final Office action; or (2) as 
set forth in (b) above, if checked. Any reply received by the Office later than three months after the mailing date of the final rejection, even if timely filed, 
may reduce any earned patent term adjustment. See 37 CFR 1 .704(b). 
NOTICE OF APPEAL 

2. □ The Notice of Appeal was filed on . A brief in compliance with 37 CFR 41 .37 must be filed within two months of the date of 

filing the Notice of Appeal (37 CFR 41 .37(a)), or any extension thereof (37 CFR 41 .37(e)), to avoid dismissal of the appeal. Since a 
Notice of Appeal has been filed, any reply must be filed within the time period set forth in 37 CFR 41.37(a). 
AMENDMENTS 

3. □ The proposed amendment(s) filed after a final rejection, but prior to the date of filing a brief, will not be entered because 

(a) HH They raise new issues that would require further consideration and/or search (see NOTE below); 

(b) \Z\ They raise the issue of new matter (see NOTE below); 

(c) □ They are not deemed to place the application in better form for appeal by materially reducing or simplifying the issues for 

appeal; and/or 

(d) Q They present additional claims without canceling a corresponding number of finally rejected claims. 

NOTE: . (See 37 CFR 1.1 16 and 41.33(a)). 

4. □ The amendments are not in compliance with 37 CFR 1.121. See attached Notice of Non-Compliant Amendment (PTOL-324). 

5. n Applicant's reply has overcome the following rejection(s): . 

6. □ Newly proposed or amended claim(s) would be allowable if submitted in a separate, timely filed amendment canceling the 

non-allowable claim(s). 

7. □ For purposes of appeal, the proposed amendment(s): a) □ will not be entered, or b) □ will be entered and an explanation of 

how the new or amended claims would be rejected is provided below or appended. 
The status of the claim(s) is (or will be) as follows: 

Claim(s) allowed: . 

Claim(s) objected to: . 

Claim(s) rejected: . 

Claim(s) withdrawn from consideration: . 

AFFIDAVIT OR OTHER EVIDENCE 

8. □ The affidavit or other evidence filed after a final action, but before or on the date of filing a Notice of Appeal will not be entered 

because applicant failed to provide a showing of good and sufficient reasons why the affidavit or other evidence is necessary and 
was not earlier presented. See 37 CFR 1.116(e). 

9. □ The affidavit or other evidence filed after the date of filing a Notice of Appeal, but prior to the date of filing a brief, will not be 

entered because the affidavit or other evidence failed to overcome all rejections under appeal and/or appellant fails to provide a 
showing a good and sufficient reasons why it is necessary and was not earlier presented. See 37 CFR 41 .33(d)(1 ). 

1 0. □ The affidavit or other evidence is entered. An explanation of the status of the claims after entry is below or attached. 
REQUEST FOR RECONSIDERATION/OTHER 

11. The request for reconsideration has been considered but does NOT place the application in condition for allowance because: 
See Continuation Sheet. 

12. □ Note the attached Information Disclosure Statements). (PTO/SB/08) Paper No(s). 

13. □ Other: . 

/Weilun Lo/ /Steven B Theriau It/ 

Supervisory Patent Examiner, Art Unit 2179 Patent Examiner 

Art Unit: 2179 
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Continuation of 11. does NOT place the application in condition for allowance because: The applicant's request for reconsideration has 
been carefully reviewed and is not persuasive for the following reasons: The examiner refers to MPEP 2123 and 2144 that states that an 
entire reference cited is considered relevant for all that the reference suggests and contains and that is pertinent to one of ordinary skill in 
the art . Further the Examiner refers to 21 1 1 , and other sections, that guide the Examiner to not read limitations from the specification into 
the claims and to interpret the claims as to their plain meaning in the art. Therefore, the Examiner responds to the main argument 
presented by the applicant simply by referring to PARA 70-75, where the last two lines of PARA 70 expressly state that the updatenode 
function OCCURS ON THE CLIENT SIDE, which is considered operating WITHIN THE BROWSER. That said and turning to the 
arguments, it appears the Applicant argues that the prior art of Vaidya is not relevant art because the applicant interprets Vaidya as 
teaching a server side only process of identifying, determining and applying a change to a user interface element. In response to applicant's 
arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections 
are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 
231 USPQ 375 (Fed. Cir. 1 986). In this case, the applicant appears to argue against the teachings of Vaidya over several pages and limits 
the argument on Lewallen and argues that the Examiner has not addressed all of the issues of the claims. It is clear from the rejection on 
Page 3 and Page 4, that the Examiner relied on both references to teach the combined limitations of claim 1 and the dependent claims. The 
structure of both references is pertinent to one of ordinary skill in the art. The Examiner also provided several statements as to the 
interpretation of Vaidya in view of Lewallen in the final rejection (See page 4 and below) describing how the limitations of Vaidya and 
Lewallen teach the recited claims and is stumped as to how to clarify further other then this action what is understood by one of ordinary 
skill in the art. Applicant's first argument presents evidence that Vaidya manages data in a backend database and refers to Para 93 as 
stating that the data is on the server only, which is the paragraph the examiner relies on in the rejection along with Para 47-48 and Para 67. 
These Paragraphs teach the features of Vaidya as the process of IDENTIFYING in a browser a user interface element received from a 
server as the elements are received from a server to be presented on the client. Surely, the teachings of Vaidya show that the layered data 
set is a scheme for access to different levels of user interface elements on a DOM tree because a folder, file menu, font and frames are 
understood as unmistakable terms in interfaces as elements displayed to a user (See Figure 2). Accordingly, the feature of the claims that 
refer to an interface element are implied in Vaidya. Para 47, specifically states the user has accessed the data set, which is a mechanism 
for IDENTIFYING a user interface element. As presented in the rejection, a DOM tree is a representation of all of the data and elements 
rendered in a browser. Therefore, if the user accesses the data set then they are accessing a DOM element. Second, Vaidya teaches 
setting the state attribute IN THE CLIENT for signifying that an element has been changed (See PARA 70) " the update node function 
performs the operations ON THE CLIENT SIDE, which is not a function on the server, contra to what the applicant argues. Moreover, in 
combination with Lewallen, which the rejection relies for the combination of features of the claims, Lewallen teaches that a change in a Ul 
element has been received and determines that the change can be applied to the DOM hierarchy, IN THE CLIENT AND NOT ON THE 
SERVER (See Lewallen Figure 5 and 6 and column 7, lines 60-67 and column 8, lines 1-15 and column 11, lines 1-15) as Lewallen is 
specifically directed to updating user interface elements in the browser. Vaidya suggests that the CHANGE function MAY RESIDE ON THE 
SERVER, which suggests to one of ordinary skill in the art, that the function may reside on the client and Lewallan is an example of such a 
client. Vaidya also teaches that the computer can wholly reside on the client side (See Para 92). Therefore, while the examples show 
client/server processing, the suggestions in the reference show otherwise. Lewallen is an example of where the processing can occur on 
the client and suggests the need to allow the processing to occur in the browser for converting OBJECTS in a first interface format to a 
second format and was used in combination to reject all of the features of the claims. The second argument presented by applicant appears 
to conclude that the data set is "cached in a server as a DOM tree"and refers to Para 65. The Examiner does not dispute the function as 
shown in Vaidya however, as mentioned above, the update node function OPERATES ON THE CLIENT as taught in PARA 70. The 
merging of the tree from the database occurs on the server but it is the user that through selection makes the IDENTIFICATION on the 
CLIENT. The language of Para 70, line 5, expressly states the update node function "performs a variety of operations ON THE CLIENT". 
Further, Figure 9 expressly shows that there are two memory locations for the DOM. While the applicant appears to mention the cache 
exists solely on the server side Figure 9 dictates otherwise. Figure 9, #901 and 965 shows a link through 960" to 955 and 950 on the server. 
The teachings of Para 93 apply here where Vaidya shows the recreation of a tree on the client side,which is a stored representation of the 
tree. The purpose of the stored tree is to allow the update node function to operate on the node locally. The fourth argument, the applicant 
argues that Vaidya does not describe what is recited in the claim, where Vaidya does not teach identifying anything in a browser. The 
Examiner agrees to disagree with the applicant on this issue. Figure 2, 204 expressly shows an applprofile for Netscape, which is a browser 
application. Second, Vaidya teaches the computing system is an Internet computing device (See Para 94) and the ISP provides 
communications through the world wide packet network often referred to as the Internet (See Para 91). Therefore, the structure of Vaidya 
teaches a browser based system. Applicant argues that Vaidya does not teach an interface page and once again the Examiner agrees to 
disagree with applicant, as it is noted that at first glance of the Vaidya reference and without careful interpretation of the language of the 
reference it would be easy to interpret the layers of data of Vaidya as merely data and that the interfaces presented to the user are cursory. 
However, the Examiner contends that one cannot move or signify to move a location of the "my documents" location without interacting with 
an interface. One cannot interface with the computer to update attributes of the login information, passwords/certificates, personal data, etc 
as mentioned in Para 15, without viewing the interface. Further, Vaidya teaches the settings are for desktop applications, in Para 24, which 
provides evidence that the user interfaces with the system to change the settings through a browser, or other application interface on the 
desktop. Moreover, as expressly taught in Lewallan a DOM is a standard interface of documents and in broad terms encompasses a 
definition of application components such as Ul elements (See column 4, lines 12-26) and that MANY browsers implement the DOM (See 
column 33-35). The present application specification describes elements as the following: "[0006] Applications that are built according to 
the model-view-controller (MVC) design methodology provide views that present an application model to a user. The user can interact with 
the views, causing a corresponding controller to manipulate the model. The model can then update its views as appropriate. A Ul page of 
an application can include multiple views. The structure of a Ul page can be described as a Ul tree structure, where the root node of the 
tree represents the Ul page, and child nodes represent Ul elements included in the page. The Ul elements can include one or more views 
and one or more controls through which a user interacts with, provides input to, and/or controls the application. Some examples of 
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controls are text fields, radio buttons, tables, trays, and drop-down menus. Each node can have further child nodes (for example, to 
represent nested views). 

[0007] An application running on a server computer can send a Ul page with markup language portions that describe the Ul elements of a 
Ul page to a client computer with a browser. The client can parse the markup language portions of the Ul page and build a document object 
model (DOM) of the Ul page. The DOM (e.g., HTML DOM) can include nodes in a DOM hierarchy that represent the Ul elements of the Ul 
page in the browser. The browser presents a screen presentation of the Ul page that corresponds to the DOM. " 

Therefore, using the applicant's definition of an element to meet the limitations of the claim, a user interface element can include one or 
more controls that the user interacts with and the controls are a part of a Ul page that includes a root node and child nodes as elements of 
the page. Vaidya Figure, 2, shows a DOM tree with a root node that defines settings for multiple interface pages for a user and the 
elements of an interface page, can be the elements as described in figure 2, as the menu controls, folders, frames, colors, fonts etc. The 
applicant requests a supplemental action to describe the basis of the rejection as applied by the Examiner and in response the Examiner 
suggests that the response to arguments in the final, this advisory, and the rejection provide ample discussion as to how the Examiner 
interprets the prior art. In looking at the file wrapper, the applicant has not exercised their privilege to contact the Examiner for an interview. 
MPEP 408 states that a call may be placed to the Examiner if the practitioner feels that the call would be beneficial to the case. In this case, 
the Examiner would be available for further clarification of the rejection, if need be, at applicant's request but after final interviews should be 
requested with an agenda to discuss how prosecution can be advanced and how an interview can serve to develop and clarify issues that 
lead to an understanding between the Examiner and the applicant. Finally, claim 1 as a whole can be interpreted and summarized by the 
Examiner as follows: In a apparatus, IDENTIFY, in a browser, a change to a Ul element, the element contained in a page sent from the 
server and rendered on a screen and the change occurring after the page was received. DETERMINE if the change can be applied to the 
element by applying a delta renderer with functions that can change the Ul element. IF the change can happen through the delta render 
then modify the element, IF NOT then set the flag. Therefore, the plain meaning of IDENTIFYING a node in a browser that is a Ul element 
is taught by the combined teachings of Vaidya and Lewallen as outlined by the rejection because the updatenode function of Vaidya 
operates in the client and changes the node attribute to modified that is seen by the server. Second, the DETERMINATION as to whether a 
change can occur is managed by a delta renderer. The present application specification states: "A delta renderer is a set of update 
functions that can modify the DOM representation of a Ul element directly by using, for example, setter functions for various attributes of 
the Ul element (e.g., setValue, setMaxLength, setColor, etc.)." Vaidya clearly teaches a mechanism to update state ATTRIBUTE of the 
elements by changing the element attribute to MODIFIED, DELETED or REPLACED. Finally, Vaidya teaches the update occurs on the 
CLIENT SIDE as shown in Para 70-75. The server would then sync the trees looking for the updated nodes as shown in Para 78. The 
Examiner notes, that the rejection states the Vaidya does not teach a delta renderer. Vaidya teaches the process of updating node 
attributes and Lewallen suggests using a delta renderer because Lewallen teaches a bridge that transforms browser calls through the API 
to access the Ul object and to execute the mixed program statements directly in the browser to MANIPULATE THE Ul DOM (See column 7, 
lines 30-67 and column 8, lines 1-15, 45-67 and column 9, lines 15-30 and column 10, lines 54-67 and column 11, lines 1-15). Vaidya 
teaches that the node attribute setting can be OVERRIDDEN with a new attribute (See Para 71) , which is a mechanism for updating the 
node but does not teach a delta renderer and as explained Lewallan was used in combination with Vaidya because the Bride object of 
Lewallen teaches the setting method of accessing the interface object to make changes in the browser. The rest of applicant's arguments 
revolve around the same issue and that being that applicant does not interpret the teachings of Vaidya as having an interface, as being a 
CLIENT SIDE operation and as describing interface elements with a page. As presented, above the Examiner agrees to disagree with 
applicant on the interpretation of the art and as explained above along with the arguments presented in the final, the claims remain rejected 
over the final rejection mailed 02/07/2008. 
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